Garbage collection system

ABSTRACT

A garbage collection (GC) system reducing CPU time required for GC without stopping all Application Program threads for an excessive amount of time. The GC system frees memory areas corresponding to objects that are no longer required in an execution procedure of an object-oriented program including a plurality of threads. The GC system includes a selection unit operable to select the threads, an examination unit operable to examine the selected thread by (i) stopping execution of the thread, (ii) finding an object that is accessible from the thread via an object pointer, (iii) managing the found object as a non-freeing target, and (iv) resuming execution of the thread. The GC system also includes a detection unit operable to manage an object identified by the processing target object pointer, as a non-freeing target, and a freeing unit operable to free memory areas corresponding to objects other than the objects that are non-freeing targets.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to garbage collection (GC) in a memoryused by an application program (AP).

2. Background of the Related Art

In some conventional object oriented programming languages, freeing ofmemory area corresponding to objects (also called “object instance”)that are no longer required after being used by an AP is theresponsibility of the execution environment. Employing such a methodrelieves the creator of the AP from being concerned with allocation andfreeing of memory area. One example of an object oriented programminglanguage is Java. Note that Java is a trademark of the Sun MicrosystemsInc., of the USA.

An AP written using such a language is run on an execution environmentthat includes a garbage collection (GC) mechanism that automaticallyfrees the memory area corresponding to objects that are no longerrequired.

When an AP is being executed, the GC configuration detects that a memoryarea corresponding to a dynamically-allocated object is not beingreferenced from anywhere, and frees the memory area so that the memoryarea is in a reusable state.

In a multithreaded AP, each thread corresponds to a stack area, and, inan operation process, stores data in the stack area, refers to storeddata, and generates an object. Ordinarily when an object is generated, apointer for the object (hereinafter called an “object pointer”) isstored in the stack area. The object pointer is data indicating thelocation of the object in the memory. The object is accessed from thethread by referring to the object pointer. Furthermore, ordinarily, anobject pointer to another object is also stored in the object.

All objects that are being referenced by the AP at a particular point intime can be reached either directly from an object pointer included inone of the stack areas corresponding to the threads, or via the objectpointers in one or more objects.

In response to this, the GC mechanism essentially determines that amemory area corresponding to an object that is no longer reachable froman object pointer in a stack at a particular point in time is no longerrequired, and frees the memory area.

One conventional GC method is mark-and-sweep. The mark-and-sweep methodmarks all objects that can be reached from an object pointer, then scansall objects, and frees memory area corresponding to objects that are notmarked.

When this mark-and-sweep GC is performed during the execution of amultithreaded AP, priority may be given to prompt performance of GC. Todo so, marking of all objects that can be reached from an object pointerin the stack corresponding to each thread is performed after simplystopping all threads. Then the stop on all the threads is released, andobjects that are not marked are freed. However, the following problemoccurs in such a case.

Specifically, there is a possibility that all the threads of the AP willbe stopped for a relatively long time. During this time, the computerdoes not react to user operations or the like, and, as one example, thedisplay contents on the display of the computer may remain the same.This causes confusion for the user.

One method for solving this problem is disclosed in Japanese Patent No.3027845. This method proposes GC using mark-and-sweep that is executedwithout stopping a multithreaded AP at all.

With this method, first processing is performed for marking all objectsthat can be reached from an object that is a root node and all objectsthat can be reached from object pointers in the stack area for eachthread. Second processing is then performed, when an object pointer toan object has moved due to an operation of a thread of an AP(hereinafter called an, “AP thread”) during the first processing, and isfor stacking data expressing that object in a mark stack area, and whenthe marking processing is complete, further marking all objects that canbe reached from the mark stack. Finally, memory areas corresponding tounmarked objects are freed.

However, with this method that marks without stopping the AP, there is apossibility that, since data in the stack area changes due to AP threadoperation, part of the processing for marking objects that can bereached from the object pointer in the stack area will be wasteful.

Take, for example, the following case. While a thread for garbagecollecting is executing processing (here, called “processing A”) fordetecting an object pointer (here, called “object pointer A”) in onestack area of the AP and marking objects that are reachable from theobject pointer A, the AP thread corresponding to the stack area copiesthe object pointer A or the one or more object pointers in the objects,and newly stores the copied object pointer A or object pointers in astack area. Here, the thread that performs GC will, after ending theprocessing A, either perform processing that duplicates the processing Ain part, or perform check processing to prevent duplicate processing.Either processing will be wasteful. This wasteful processing leads to anunnecessary increase in the CPU time required from start to completionof GC, and consequently lowers the usage efficiency of the CPU.

BRIEF SUMMARY OF THE INVENTION

The present invention was conceived in view of the stated problem, andhas an object of providing a garbage collection (GC) system that uses aGC method which prevents the time for which all threads of an AP arestopped from being excessively long, and which suppresses, to an extent,wasteful increases in CPU time taken from the start to completion of GC.

In order to achieve the stated object, the present invention is agarbage collection system that frees memory areas corresponding toobjects that are no longer required in an execution procedure of anobject-oriented program composed of a plurality of threads, the garbagecollection system including: a selection unit operable to select thethreads one at a time; an examination unit operable to executeexamination processing with respect to the selected thread, theexamination processing including procedures of stopping execution of thethread, finding an object that is accessible from the thread byreferring to an object pointer, managing the found object as anon-freeing target, and resuming execution of the thread; a detectionunit operable to, when having detected, after the selection unit hascommenced selecting, that an object pointer has been processed as aprocessing target by a currently-executed thread, manage an objectindicated by the processing target object pointer, as a non-freeingtarget; and a freeing unit operable to, after the examination processinghas been completed with respect to all of the threads, free memory areasthat correspond to objects other than the objects that are managed asnon-freeing targets.

Here, an object pointer being processed as a processing target by athread means that, in the processing procedure of the thread by the CPU,an instruction is executed that processes the object pointer as aprocessing target.

Furthermore, managing an object as a non-freeing target denotes therealization of marking by using a method such as that described laterthat moves the object pointer from a from table to a to table.

According to the stated structure, an AP thread is stopped in theprocedure for designating non-freeing targets that are objects that canbe reached from the AP thread via an object pointer which is in thestack or is in an object. This avoids a situation in which operation ofthe AP thread causes data in the stack area to change, and thereforeprevents the risk of marking processing performed during the procedurebecoming wasteful. This prevents lowering of the CPU usage efficiency.

Furthermore, according to the stated structure, since not all AP threadsare stopped to perform marking processing, the time for which allthreads of the AP are stopped can be prevented from being excessivelylong. Note that while changes may occur in the state of referencing toobjects because not all AP threads are stopped, these changes are dealtwith by monitoring whether object pointers have been processing targetsof currently-executed threads. Therefore, objects that are accessiblefrom any of the threads are always managed as non-freeing targets.

Furthermore, the detection unit may perform the detection only when thecurrently-executed thread has not yet been subject to examinationprocessing, and the detection unit may include: a finding sub-unitoperable to, when having performed the detection, store, to a workingmemory area that corresponds to the currently-executed thread, theprocessing target object pointer and an object pointer in an object thatcan be reached from the processing target object pointer; and amanagement sub-unit operable to, while execution of a thread is beingstopped by the examination unit, manage, as a non-freeing target, anobject that can be reached from the object pointer in the working memoryarea corresponding to the thread.

According to the stated structure, only while the thread is the targetof reference processing described later, in other words, only while thethread is a target of processing that corresponds to marking objectsindicated by object pointers stored in the stack or the like thatcorresponds to the thread, (i) processing is performed for detectingthat the object pointer was a processing target of the thread duringexecution by the interpreter, and (ii) storing the object pointer in theworking memory, in other words, storing the object pointer in the memoryarea of the object reference information. Therefore, after the threadhas been a target of reference processing, the thread can operate morequickly because the thread is not subject to detection during executionby the interpreter.

Furthermore, the examination processing may be processing for, when anobject indicated by an object pointer in a stack corresponding to theselected thread is found to be accessible, repeatedly performing aprocedure of, only when both (a) the accessible object is not alreadybeing managed as a non-freeing target and (b) an object pointer existsin the accessible object, further finding that an object indicated bythe object pointer in the accessible object is accessible, the selectionunit may, after a first selection, further perform selection if, afterthe examination processing has been performed by the examination unit,any threads out of the plurality of threads remain that have not beensubject to the examination processing, and the selection unit may referto information about the threads, and makes the selection based one ormore predetermined thread selection conditions.

The stated structure prevents objects that come under objects managed asnon-freeing targets from being made targets of for detection induplicate. Furthermore, according to this structure which avoidsduplicate detection, the possibility is high that the time forreferencing processing with respect to threads that are subject toreference processing later will be shorter than for threads that aresubject to reference processing earlier. Therefore, by pre-determiningthread selection conditions in view of the response performance requiredby each thread, control can be performed so that, to an extent, eachthread is executed exhibiting an appropriate response performance.

Furthermore, the thread selection conditions may include a conditionindicating that any threads whose thread state is a wait state are to beselected before any threads whose thread state is a state other than thewait state, and if a thread whose thread state is the wait state existswhen making the selection, the selection unit may select the threadwhose state is the wait state.

According to the stated structure, the thread that is stopped is athread in the wait state. This prevents adverse affects on the AP threadcurrently operating.

Furthermore, the thread selection conditions may include a conditionindicating that any threads, whose thread priority level is low, are tobe selected before any threads whose thread priority level is high.

According to the stated structure, lowering of execution performance canbe prevented to an extent because the possibility is high that referenceprocessing for threads with a high thread priority will be performed ina relatively short amount of time.

Furthermore, the thread selection conditions may include a conditionindicating that any threads whose corresponding stack size is small areto be selected before any threads whose corresponding stack size islarge.

The stated structure takes of advantage of the tendency for the timerequired for reference processing to be shorter, the smaller theeffective range is of a stack that stores an object pointer to an objectthat is accessible from a thread. This structure achieves an effect ofbeing able, to an extent, to make the time for which the threads arestopped even between threads, and avoids, to an extent, a situation inwhich the response performance of a particular thread is especially badcompared to other threads.

Furthermore, the garbage collection system may further include a memorymanagement mechanism that manages memory with use of a memory managementunit (MMU), wherein each time an object is to be generated, a memoryarea corresponding to the object is allocated by the memory managementmechanism, and the freeing unit frees the memory areas via the memorymanagement mechanism.

According to the stated structure, memory areas are allocated to objectsin the same way as for program data and the like written in a languagesuch as C language, by the memory management mechanism that uses an MMU.Since it is not necessary to allocate a heap area before generatingobjects, this structure is advantageous compared with a structure inwhich control is performed to separately manage an unnecessarily largeheap area and allocate part of the heap area as a memory area for anobject. Furthermore, this structure is advantageous in that memorycompaction of a heap area is unnecessary.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram of a GC system of a firstembodiment of the present invention;

FIG. 2 shows an example of the relationship between objects and objectpointers;

FIG. 3 shows a “from” table and a “to” table;

FIG. 4A shows the state of the “from” table before reference processing;

FIG. 4B shows the state of the “from” table and the “to” table afterreference processing;

FIG. 5 shows thread information, a stack, and object referenceinformation;

FIG. 6 shows the relationship between reference processing and the stateof AP threads;

FIG. 7 shows the contents of thread selection conditions;

FIG. 8 is a flowchart showing GC control processing;

FIG. 9 is a flowchart showing target thread determination processing;

FIG. 10 is a flowchart showing shared object reference processing;

FIG. 11 is a flowchart showing target thread reference processing;

FIG. 12 is a flowchart showing reference processing;

FIG. 13 is a flowchart showing instruction execution processing;

FIG. 14 is flowchart showing object chain tracing processing;

FIG. 15 is a functional block diagram of a GC system of a secondembodiment of the present invention;

FIG. 16 shows thread information and a stack;

FIG. 17 is a flowchart showing GC control processing of the secondembodiment;

FIG. 18 is a flowchart showing instruction execution processing of thesecond embodiment; and

FIG. 19 shows Java objects managed by a conventional Java executionenvironment, and arrangement in a memory of the Java objects and data ofa C language program.

DETAILED DESCRIPTION OF THE INVENTION 1. First Embodiment

The following describes a garbage collection (GC) system of the firstembodiment of the present invention with reference to the drawings.

<1-1. Structure>

FIG. 1 is a functional block diagram of the GC system of the firstembodiment of the present invention.

A GC system 10 is realized in a computer that includes a CPU, a memory,and so on, by the CPU executing control programs stored in the memory.The GC system 10 includes a general operating system (OS) that performsmultithreaded control, and a so-called virtual machine, and is providedas an execution environment for application programs created inlanguages such as Java.

The GC system 10, as shown in FIG. 1, is composed of an interpreter 100,an object management unit 200, a thread management unit 300, and a GCunit 400.

Here, the interpreter 100 is essentially an interpreter that has afunction of executing APs, and includes an instruction execution unit110 and an object reference detection unit 120.

The object management unit 200 has a function of managing objects, andincludes an object management information storage unit 210, an objectgeneration unit 230, and a table switching unit 240. The objectmanagement information storage unit 210 is a memory area thatcorresponds to a “from” table 221, a “to” table 222, and so on.

Note that the “from” table 221 is provided for storing all objectpointers corresponding to all objects that exist before GC commences.The “to” table 222 is used to store object pointers of objects that havebeen marked according to mark-and-sweep. These tables are described indetail later.

The thread management unit 300 has a function of realizing multithreadedcontrol and managing threads. The thread management unit 300 includes athread control unit 310, and memory areas that correspond to separatethread information 320, object reference information 330, and a stack340 for each AP thread.

Note that the thread information 320 includes a GC flag for each APthread that is set ON at the start of overall GC processing and then setto OFF when reference processing with respect to the corresponding APthread has ended. The reference processing is processing for markingobjects, and is mainly for moving, from the “from” table 221 to the “to”table 222, object pointers that are identical in content to objectpointers stored in stacks and so on for the purpose of referencingobjects.

The GC unit 400 is essentially a garbage collector, and includes a GCcontrol unit 410, a thread selection condition storage unit 420, areference processing unit 430, and a freeing unit 440. GC that isperformed primarily by the GC unit 400 essentially uses themark-and-sweep method, and successively selects AP threads as areference processing target, stops the selected AP thread, and afterperforming reference processing, removes the stop from the thread.

The instruction execution unit 110 of the interpreter 100 has a functionof (i) consecutively interpreting an instruction stream that makes up anAP thread, and (ii) when an instruction is an object generateinstruction, having the object generation unit 230 generate an object.

The object reference detection unit 120 has a function of, when aninstruction in a thread executed by the instruction execution unit 110is an instruction that processes the object pointer of an object aprocessing target, storing the object pointer in the memory area of theobject reference information 330. Note that the object referencedetection unit 120 performs this function only when the GC flag is ON.

The object generation unit 230 of the object management unit 200 has afunction of generating an object in the memory by referring to objectdefinition information such as class files and making a request to aconventional OS memory management mechanism for allocation of a memoryarea of a size necessary for the object. Note that the GC system 10includes a conventional OS memory management mechanism that uses amemory management unit (MMU) to associate physical memory with logicaladdress spaces, and manage allocation and freeing of the memory. Thismemory management mechanism has a function of, when a request isreceived for a memory area of a particular size, managing a memory areaof the requested size, from among unused area of the logical addressspace, as an assigned memory area, and returning the top address of theassigned memory area. Consequently, the object generation unit 230generates an object in the memory by assigning an area in the logicaladdress space corresponding to the object through the memory managementmechanism.

Note that in addition to AP objects created in a language such as Javaand executed by the interpreter 100, the logical address space also hasarrayed therein program data that is executed under the direct controlof a conventional OS, without going through the interpreter 100. Inother words, data of programs that have already been put in anexecutable format by a compiler or the like. This data is referred to as“native data” hereinafter. Programs that are in a format executablewithout going through the interpreter 100 are allocated memory area viathe conventional OS memory management mechanism for arraying nativedata. Allocation of the memory area for objects generated by the objectgeneration unit 230 is performed in the same manner as arranging nativedata in the memory area.

Such native data and programs relating to the native data are notdirectly relevant to the GC operations that are the feature of the GCsystem 10, and therefore a detailed description thereof is omitted fromthe present description.

Note that the term “AP thread” used above refers to a thread that is aunit of execution of an AP executed via the interpreter unit 100, inother words, a thread other than a unit of execution of a programrelating to native data. Furthermore, the term “object” used here doesnot include native data.

The table switching unit 240 has the function of causing an effect thatis equivalent to the contents of the “from” table 221 being instantlyexchanged with the contents of the “to” table 222, by exchanging apointer used to indicate the “from” table 221 with a pointer used toindicate the “to” table 222.

The thread control unit 310 of the thread management unit 300 performsmultithreaded control, and serially executes threads including APthreads that make up AP and GC processing threads. That is, the threadcontrol unit 310 switches and executes threads at minute time intervals.Note that the thread management unit 300 also serially executes programthreads of native data. However, since this multithreaded controlfunction is essentially a function in conventional OSs and the like, andis not directly relevant to the GC operations that are the feature ofthe GC system 10, the present description focuses primarily onprocessing of AP threads and GC threads only.

The thread selection storage unit 420 of the GC unit 400 is a memoryarea that stores thread selection conditions showing conditions forselecting an AP thread as a target of reference processing.

The reference processing unit 430 has the function of performingreference processing. The freeing unit 440 has the function of freeingobjects that have not been marked. In other words, the freeing unit 440frees memory area corresponding to an object indicated by an objectpointer that exists in the “from” table 221 at the end of GC. Freeing ofthe memory area is realized by designating the object pointer, in otherwords the logical address of the object, and making a freeing request tothe conventional OS memory management mechanism that uses an MMU. Notethat, in response to the request to free the designated logical address,the conventional OS memory management mechanism included in the GCsystem 10 manages the area allocated to the in association with thelogical address as an unused memory area that can be newly allocatedwhen it is necessary to allocate memory area.

Furthermore, the GC control unit 410 has the function of executing GCcontrol processing. Specifically, the GC control unit 410 selects one APthread as a target of reference processing by referring to the threadselection conditions. After having the thread control unit 310 stop theselected AP thread, the GC control unit 410 then has the referenceprocessing unit 430 perform reference processing based on the stack andobject reference information corresponding to the AP thread. Next, afterhaving the thread control unit 310 release the stop on selected APthread, the GC control unit 410 selects the next AP thread. The GCcontrol unit 410 repeats the described procedure until no unprocessed APthreads exist, and then has the freeing unit 440 free objects that havenot been marked.

<1.2 Data>

The following describes data treated in the GC system 10.

FIG. 2 shows an example of the relationship between objects and objectpointers.

In the drawing, object pointers are expressed as small, filled-incircles.

Object pointers which indicate an object, in other words, which indicatean address location of an object arranged in the logical address spacecorresponding to the memory 500, may exist in either an object, a stack,or shared object management information 353. Here, the shared objectmanagement information 353 is data that includes an object pointer groupthat indicates an object group allocated, because it is necessary in avirtual machine as an AP execution environment.

In the example in FIG. 2, the object pointer in the shared objectmanagement information 353 indicates an object 201 c.

Furthermore, one object pointer in the stack that corresponds to an APthread 351 indicates an object 201 a, in other words the contents of thememory address of the object 201 a. The other object pointer in thestack that corresponds to the AP thread 351 indicates an object 201 d.Therefore, the AP thread 351 is able to access the object 201 a and theobject 201 d during execution by referencing these object pointers.

Furthermore, the object pointer in the stack corresponding to the APthread 352 indicates an object 201 b, and an object pointer thatindicates an object 201 e is included as data in the object 201 b.Therefore, the AP thread 352 is able to access the object 201 e bytracing these object pointers.

Furthermore, FIG. 2 shows that, together with the objects 201 a to 201 ethat correspond to APs created in a language such as Java executed viathe interpreter 100, native data 501 a to sold whose memory area is alsoallocated by the OS memory management mechanism exists in the memory500. Areas are allocated to this native data 501 a to 501 d also by thememory management mechanism of the OS. In other words, the objects 201 ato 201 e are not put together into a type of heap area, but are assignedrespective, separate areas by the OS memory management mechanism in thesame way as native data.

Note that although not shown in FIG. 2, thread information 320, a stack340, and object reference information 330 are also allocated areas inthe memory 500. Furthermore, the object reference information storageunit 210 corresponds to part of the memory 500. Note that the programportion of the AP executed via the interpreter 100 and the programportion that accesses the native data may be stored in areadable/writable memory (RAM), or in a read only memory (ROM).

FIG. 3 shows the from table and the to table.

In the object management information storage unit 210 of the memory 500,two data areas are provided that are for storing a sufficient number ofobject pointers or null values. A “from” table pointer 211 and a “to”table pointer 212 also exist in the object management informationstorage unit 210. The “from” table pointer 211 indicates one of the twotables, and the “to” table pointer 212 indicates the other of the twotables. Here, the table presently indicated by the “from” table pointer211 is called the “from” table 221, and the table presently indicated bythe “to” table pointer 212 is called the “to” table 222.

At the point when GC commences, the “from” table 221 stores objectpointers that correspond all objects that exist at that time.

Furthermore, the “to” table 222 stores object pointers that are movedfrom the “from” table 221 during reference processing. Note that when anobject pointer is moved from the “from” table 221 to the “to” table 222,the contents of the memory of the location in the “from” table 221 atwhich the moved object was stored are made a null value.

FIG. 4A and FIG. 4B show changes in the contents of the “from” table 221and the “to” table 222 due to reference processing. FIG. 4A shows thestate before reference processing starts, and FIG. 4B shows the stateafter reference processing.

In FIG. 4A, a “from” table 221 x before the start of referenceprocessing includes object pointers that indicate objects objA 202 a,objB 202 b, and objC 202 c, respectively. Note that FIG. 4A and FIG. 4Balso express that both objects and native data exist in the memory 500.

When reference processing is subsequently performed with an AP thread354 as a target, data having the same value as the object pointerincluded in the stack of the AP thread is moved from the “from” table221 to the “to” table 222. The result of this move is the state shown inFIG. 4B. The place where the object pointer indicating objA 202 aexisted and the place where the object pointer indicating objC 202 cexisted in the “from” table 221 y are updated to null values, and theobject pointer indicating objA 202 a and the object pointer indicatingobjC 202 c are stored in the “to” table 222 y.

FIG. 5 shows thread information, stacks, and object referenceinformation.

Thread information 320 is generated each time an AP thread is generatedfor that AP thread, and includes information about that AP thread.Specifically, the thread information 320 includes a state 321, apriority level 322, a stack pointer 323, a GC start stack pointer 324,aGC flag 325, an object reference information top pointer 326, and anobject reference information current pointer 327. Note that when an APthread is generated, a memory area is allocated not only in the threadinformation 320, but also in the stack 340.

The state 321 in the thread information 320 is information that showsthe state of the thread for the purpose of multithreaded control, andindicates either a wait state, a run state, or a ready state.

The priority level 322 is information that shows the priority level ofthe thread. The priority level is set, for example, by a designationreceived from the AP when the thread is generated. Note that inmultithreaded control, if a high priority level thread is in the readystate, the high priority thread is put into a run state before lowerpriority level threads.

The stack pointer 323 shows the end of the range of currently effectivedata in the stack relating to the thread. Note that in multithreadedcontrol, when a thread is switched from the run state to another state,in other words to a stopped state, the value stored in a predeterminedregister that has indicated the stack pointer until that point in timeis stored in the stack pointer 323, and when the thread is switched tothe run state, the value in the stack pointer 323 is set in thepredetermined register.

The GC start stack pointer 324 shows the end of the range of effectivedata in the stack at the time of starting GC.

The GC flag 325 is set to ON at the overall start of GC processing, andis set to OFF when reference processing with respect to the AP threadhas ended.

The object reference information top pointer 326 shows the head of thememory area of the object reference information corresponding to the APthread, and is set at the time of allocating memory area during APthread generation.

Furthermore, the object reference information current pointer 327 isinformation showing a location where the object reference detection unit120 is to store the next object pointer in the memory area of the objectreference information corresponding to the AP thread. The objectreference information current pointer 327 is referenced and updated bythe object reference detection unit 120.

FIG. 6 shows the relationship between reference processing and the stateof an AP thread.

The GC thread 356 is a thread for executing GC by the GC control unit410. The processing that the GC thread 356 performs is GC successivereference processing with respect to the AP threads. Here, an example isshown of reference processing being performed with respect to AP thread355 a, AP thread 355 b, and AP thread 355 c, in the stated order.

The AP thread 355 a has been subject to reference processing, and isbeing executed. Here, “being executed” means that the thread is not in asleep state, in other words, not in a stopped state, and continuouslychanges state instantaneously to a run state or a ready state, forexample.

The AP thread 355 b is in a state of being subject to referenceprocessing, and is stopped. Reference processing is performed byforcedly putting the AP thread into a stopped state, and referencing thestack and object reference information.

The AP thread 355 c is in a state of not yet having been subject toreference processing, and is being executed.

FIG. 7 shows the contents of the thread selection conditions.

Thread selection conditions 421 is information that serves as a basisfor judging which AP thread to give preference to as a target ofreference processing, and is composed of a thread state 422, a threadpriority level 423, and a stack size 424.

The thread state 422 is information showing which state of AP threadsare to be given preference. The example in FIG. 7 shows that AP threadsin the wait state are to be given preference over AP threads in statessuch as the run state.

The thread priority level 423 is information showing whether the APthread to be selected as the target of reference processing should beone having a high priority level or one having a low priority level. Theexample in FIG. 7 shows that AP threads having a low priority level areselected preferentially.

The stack size 424 is information showing whether an AP thread should beselected with preference given to AP threads whose corresponding stackarea has a large effective range or to AP threads whose correspondingstate area has a small effective range. The example in FIG. 7 shows thatAP threads whose corresponding stack area has a small effective rangeare to be selected preferentially.

<1-3. Operations>

The following describes operations of the GC system 10.

FIG. 8 is a flowchart showing GC control processing.

GC control processing is performed in a fixed cycle based on a timer.

The GC control unit 410 first switches the contents of the “from” table221 and the “to” table 222 by exchanging the contents of the “from”table pointer 211 with the contents of the “to” table pointer 212 (stepS11). The resulting state is that object pointers indicating all objectsthat are currently not freed are stored in the from table.

Next, the GC control unit 410 (i) has the thread control unit 310 stopall AP threads (step S12), (ii) sets the GC flag 325 in the threadinformation for each AP thread to ON, and (iii) sets the current stackpointer as the GC start stack pointer 324 in the thread information(step S13). The GC control unit 410 then has the thread control unit 310release the stop from all the AP threads (step S14). At step S13, withrespect to each AP thread, the GC control unit 410 further allocates amemory area for the object reference information, and sets an objectpointer that indicates the top of that memory area in the objectreference information top pointer 326 and the object referenceinformation current pointer 327.

Note that the thread control unit 310 stops and releases the stop onthreads in the same way as a conventional OS multithreaded controlmechanism. This stopping of a thread is control for putting a threadinto a stopped state (i.e., a sleep state), and this releasing ofstopping of a thread is control for releasing the sleep state, andreturning the thread to a ready state.

After step S14, the GC control unit 410 performs shared referenceprocessing for marking objects that can be reached by tracing objectpointers in the shared object management information 353 (step S15). TheGC control unit 410 determines whether or not any non-GC processedthreads (i.e., AP threads that have not yet been selected as a target ofreference processing), exist (step S16). Note that shared objectreference processing is described later.

When any non-GC processed threads are determined to exist at step S16,the GC control unit 410 performs target thread determination processingfor selecting an AP thread as the target of reference processing (stepS17), has the thread control unit 310 stop the selected AP thread (stepS18), executes target thread reference processing with respect to thecontents of the selected AP thread (step S19), sets the GC flag 325 ofthe selected AP thread to OFF (step S20), has the thread control unit310 release the stop from the selected AP thread (step S21), and returnsto the judgment at step S16. Note that the target thread determinationprocessing and the target thread reference processing are describedlater. Furthermore, directly after step S20, the GC control unit 410frees the memory area of the object reference information correspondingto the target AP thread.

Furthermore, when no non-GC processed threads are determined to exist atstep S16, the GC control unit 410 has the freeing unit 440 free objectsthat are not marked (step S22), and ends the processing. At step S22,the freeing unit 440 frees the memory areas corresponding to objectsthat have not been moved to the to table according to referenceprocessing (i.e., objects that are indicated by object pointersremaining in the “from” table 221). Here, freeing corresponds to theobject generation unit 230 securing a memory area for allocating to anobject for object generation based on an OS memory management mechanismthat uses MMU, and denotes freeing of the allocated memory area. Notethat a memory area that has been freed is able to be newly assigned as astorage area for an object or native data.

FIG. 9 is a flowchart showing target thread determination processing.

The GC control unit 410 refers to the thread selection conditions 421 inthe thread selection condition information unit 420 to perform targetthread determination processing.

First, the GC control unit 410 refers to the thread informationcorresponding to each AP thread, and searches for AP threads whose state321 is the wait state (step S31). The GC control unit 410 determines thenumber of threads (thread count) found as a search result (step S32),and if the thread count is “one”, determines the found AP thread to bethe reference processing target thread (step S37), and ends the targetthread determination processing.

Furthermore, if the thread count of the search result at step S23 is“zero”, the GC control unit 410 searches for AP threads having thelowest priority level 322 (step S33), and judges whether or not thethread count of the search result is “one” (step S35). Furthermore, ifthe thread count of the search result at step S32 is “two or more”, theGC control unit 410 narrows down the search result by searching for theAP thread that has the lowest priority level 322 among the AP threads ofthe search result (step S34), and judges whether or not the thread countof the search result is “one” (step S35).

When the thread count is judged to be “one” at step S35, the GC controlunit 410 selects the AP thread of the search result as the target threadof AP reference processing (step S37), and ends the target threaddetermination processing.

Furthermore, if the thread count of the search result is judged not tobe “one” at step S35, in other words, if a plurality of threads havingthe lowest priority level exists, the GC control unit 410 searches forthe AP thread having the smallest stack size among the AP threads of thesearch result (step S36), determines the AP thread having the smalleststack size to be the target of reference processing (step S37), and endsthe target thread determination processing.

FIG. 10 is a flowchart showing shared object reference processing.

The GC control unit 410 focuses on the top object pointer of the sharedobject management information 353 that includes an object pointer group(step S41), and, by having the reference processing unit 430 performreference processing (step S42), marks all objects in the object groupthat are assigned because they are necessary in a virtual machine thatoperates as an AP execution environment.

FIG. 11 is a flowchart showing target thread reference processing.

The GC control unit 410 focuses on the location indicated by the GCstart stack pointer 324 corresponding to the target thread (step S51),and, by having the reference processing unit 430 perform referenceprocessing (step S52), marks all objects that can be reached from objectpointers in the stack area. Note that since the point in time at whichthe GC control processing (see FIG. 8) starts and the point in time atwhich the target thread reference processing start are different, thecontents of the location indicated by the GC start stack pointer 324 andthe contents of the subsequent locations are different to when GCstarted. However, according to the subsequent step S53 and step S54, allobjects that can be reached from object pointers that have changedaccording to operation of the target thread are marked. Therefore, whilethis may result in excessive marking, it prevents a situation in whichsome objects, despite being referenced, fail to be marked.

Next, the GC control unit 410 focuses on the location indicated by theobject reference information top pointer 326 (step S53), has thereference processing unit 430 perform reference processing (step S54),and ends the target thread reference processing.

FIG. 12 is a flowchart showing reference processing.

The reference processing unit 430 searches for an object pointer fromthe memory location being focused on (step S61), judges whether anobject pointer has been detected (step S62), and when an object pointerhas been detected, judges whether an object pointer having the samevalue as the detected object pointer exists in the “from” table 221(step S64). If such as object pointer exists in the “from” table 221,the reference processing unit 430 copies the object pointer from the“from” table 221 to the “to” table 222, and records a null value in thelocation at which the object pointer existed in the “from” table 221(step S66). The reference processing unit 430 then focuses on the top ofthe data of the object that the object pointer indicates (step S67), andreturns to step S61.

Furthermore, if it is judged at step S64 that such an object pointerdoes not exist in the “from” table 221, the reference processing unit430 focuses on the next location after the location currently beingfocused on, since the object pointer has already been moved from the“from” table 221 to the “to” table 222 (step S65), and returns to stepS61. The combination of step S65 and step S61 realizes the following:successive searching for object pointers in the shared object managementinformation 353; successive searching for object pointers in the stack;successive searching for object pointers in the object referenceinformation; and successive searching for object pointers that are datamembers of a particular object.

Furthermore, when it is judged at step S62 that an object pointer wasnot able to be detected, the reference processing unit 430 judgeswhether or not the focus location is within an object (step S63). Notethat not being able to detect an object pointer means (a) if the focuslocation is in the shared object management information 353, that anobject pointer is unable to be detected in the shared object managementinformation 353, (b) if the focus location is within the stack, anobject pointer is unable to be detected in the stack, (c) if the focuslocation is within the object reference information, an object pointeris unable to be detected in the object reference information, and (d) ifthe focus point is within an object, an object pointer not being able tobe found in that object.

When the focus location is judged to be within an object at step S63,the reference processing unit 430 next focuses on the location thatproceeded the present focus location before the present focus locationwas focused on (step S68), and then returns to step S61. According tothis step S68, the reference processing unit 430 focuses on the locationin the object that follows the object pointer that was being focused onbefore step S67.

Furthermore, when it is judged at step S63 that the focus location isnot within an object, the reference processing unit 430 ends thereference processing.

FIG. 13 is a flowchart showing instruction execution processing.

The instruction execution unit 110 of the interpreter 100 performsinstruction execution processing by successively interpreting andexecuting instruction descriptions in the program of the AP thread thatis in the run state.

First, the instruction execution unit 110 interprets and executes theinstruction in the current execution location of the AP thread (stepS71), and the object reference detection unit 120 judges whether or notthe GC flag 325 in the thread information corresponding to the AP threadis ON (step S72). If the GC flag 325 is not ON, the instructionexecution unit 110 interprets and executes the next instruction (stepS71).

If the GC flag is judged to be ON at step S72, the object referencedetection unit 120 judges whether the instruction executed by theinstruction execution unit 110 at step S71 was an instruction thatprocesses an object pointer as a processing target (step S73), and ifnot, the instruction execution unit 110 interprets and executes the nextinstruction (step S71). Note that an instruction that processes anobject pointer as a processing target is (i) an instruction thatinstructs a computation for copying the object pointer in a stack to aobject, or (ii) an instruction that instructs a computation for copyingthe object pointer in the object to another object.

When it is judged at step S73 that the instruction was an instructionthat processes an object pointer as a processing target, the objectreference detection unit 120 judges whether data of the same value asthe object pointer has been stored in the object reference informationarea (step S74), and if so, the instruction execution unit 110interprets and executes the next instruction (step S71).

If it is judged at step S74 that data of the same value as the objectpointer has not been stored in the object reference information area,the object reference detection unit 120 (i) stores the object pointer atthe location in the object reference information that is indicated bythe object reference information current pointer 327 (step S75), (ii)focuses on the object indicated by the object pointer, and (iii)performs object chain trace processing (step S76). The instructionexecution unit 110 then interprets and executes the next instruction(step S71).

Note that when the instruction executed at step S71 is an instructionfor generating an object, the instruction execution unit 110 instructsthe object generation unit 230 to generate an object. Having receivedthis instruction, the object generation unit 230 generates the object,returns the object pointer indicated by the object to the AP thread, andsets a copy of the object pointer in the to table.

FIG. 14 is a flowchart showing object chain trace processing.

The object reference detection unit 120 judges whether or not anynon-focused object pointers (object pointers that have not yet beenfocused on) exist in the object that is being focused on (step S81), andwhen any non-focused object pointers exist, focuses on one of thenon-focused object pointers (step S82), and stores the object pointerthat is being focused on to the memory area of the object referenceinformation (step S83). The object reference detection unit 120 thenfocuses on the object indicated by the object pointer being focused on,and further performs the object chain processing at steps S81 to S84(step S84). Note that after storing an object pointer in the memory areaof the object reference information, the object reference detection unit120 advances the object reference information current pointer an amountcorresponding to the size of the object pointer.

Furthermore, when it is judged at step S81 that no non-focused objectpointers exist in the object being focused on, the object referencedetection unit 120 ends the object chain trace processing.

Consequently, the result of instruction execution processing and objectchain processing is that, when the GC flag 325 is ON, object pointersthat could be reached from the object pointer that is the processingtarget when that object pointer was the processing target are stored ina memory area in the object reference information.

Note that the processing of the above-described steps S72 to S76 andsteps S81 to S84 is performed for the following reason. There are casesin which an object indicated by an object pointer becomes inaccessiblefrom a particular AP thread due to the AP thread executing computationsthat process the object pointer as a processing target. Specifically,the object indicated by the object pointer may become inaccessible fromthe AP thread when, according to AP thread operations, (a) the objectpointer is cleared, (b) the contents of the object pointer are updated,or (c) the object pointer was in an effective range of the stack areabut, due to the stack pointer being updated, is no longer in theeffective range and essentially becomes inaccessible from the AP thread.In such cases, if the AP thread has copied the object pointer to a placewhere the object pointer is accessible from another AP thread, theobject indicated by the object pointer must be marked.

2. Second Embodiment

The following describes a GC system of the second embodiment of thepresent invention with reference to the drawings.

The GC system of the second embodiment is essentially the same as the GCsystem 10 of the first embodiment in that AP threads are successivelystopped and subject to reference processing. However, the differencebetween the two is that the GC system of the second embodiment does nothave object reference information and a GC flag for each AP thread, butinstead has one set of object reference information and one GC flag forthe system as a whole. A further difference is that the GC system of thepresent embodiment reduces the content of the thread information to anextent recuired for general multithreaded control.

FIG. 15 is a functional block drawing of the GC system of the secondembodiment of the present invention.

Structural components of the GC system 20 shown in FIG. 15 that are thesame as structural components of the GC system 10 of the firstembodiment have the same numbering thereas. The present descriptionfocuses on the compositional elements that are unique to the GC system20. Note that any characteristics of the GC system not described hereshould be considered to be the same as the GC system 10.

The GC system 20, as shown in FIG. 15, is composed of an interpreter1100, an object management unit 200, a thread management unit 1300, anda GC unit 1400.

Here, the interpreter 1100 is essentially an interpreter that has afunction of executing APs, and includes the instruction execution unit110 and an object reference detection unit 1120.

The thread management unit 1300 has a function of realizingmultithreaded control and managing threads. The thread management unit1300 includes the thread control unit 310 and memory areas thatcorrespond, for each AP thread, to thread information 1320 and a stack340. Note that the thread information 1320, as shown in FIG. 16,includes a state 321, a priority level 322, and a stack pointer 323.

The GC unit 1400 is essentially a garbage collector, and includes a GCcontrol unit 1410, a thread selection condition storage unit 420, areference processing unit 1430, a freeing unit 440, object referenceinformation 1450, and a memory area that corresponds to object referenceinformation 1450 and a GC flag 1460.

The object reference detection unit 120 of the interpreter 1100 has afunction of, only when the GC flag 1460 is ON, and when an instructionof an AP thread executed by the instruction execution unit 110 is aninstruction that processes an object pointer of an object as aprocessing target, storing the object pointer in the memory area of theobject reference information 1450.

GC that is performed primarily by the GC unit 400 essentially uses themark-and-sweep method to successively select AP threads as a referenceprocessing target, stop the selected AP thread, and after performingreference processing, remove the stop from the thread.

The reference processing unit 1430 of the GC unit 1400 has the functionof performing reference processing by referring to the stack and theobject reference information 1450. The object reference information 1450is information whose contents include object pointers, in the same wayas the object reference information of the GC system 10, but does notexist separately for each AP thread. Stored in the memory area of theobject reference information are all objectpointers that have been aprocessing target of an instruction by the object reference detectionunit 1120 by AP threads. Note that the thread information 1320, thestack 340, the object reference information 1450, and the GC flag 1460are stored in the same way as objects and native data in the memory thatincludes the object management information storage unit 210.

Furthermore, the GC control unit 1410 has the function of execution GCcontrol processing shown in FIG. 17.

FIG. 17 is a flowchart showing GC control processing of the secondembodiment. Note that the steps in the flowchart that are the same assteps in the GC control processing of the first embodiment have the samenumbering as in FIG. 8.

This GC control processing is performed in a fixed cycle based on atimer.

The GC control unit 1410 first switches the contents of the from tableand the to table by exchanging the contents of the from table pointer211 with the contents of the to table pointer 212 (step S11), and setsthe GC flag 1460 to ON (step S111).

After step S111, the GC control unit 1410 performs shared referenceprocessing for marking objects that can be reached by tracing objectpointers in the shared object management information 353 (step S15). TheGC control unit 410 determines whether or not any non-GC processedthreads, in other words AP threads that have not been selected as atarget of reference processing, exist (step S16).

When any non-GC processed threads are determined to exist at step atstep S16, the GC control unit 410 performs target thread determinationprocessing for selecting an AP thread as the target of referenceprocessing (step S17), has the thread control unit 310 stop the selectedAP thread (step S18), focuses on the location of the stack pointercorresponding to the selected AP thread (step S112), has the referenceprocessing unit 1430 execute reference processing (see FIG. 12) (stepS113), has the thread control unit 310 release the stop from theselected AP thread (step S21), and returns to the judgment at step S16.

Furthermore, when no non-GC processed threads are determined to exist atstep S16, the GC control unit 410 has the thread control unit 310 stopall AP threads (step S114), focuses on the top location of the memoryarea of the object reference information (step S115), has the referenceprocessing unit 1430 execute reference processing (step S116), sets theGC flag 1460 to OFF (step S117), has the thread control unit 310 removethe stop from all AP threads (step S118), has the freeing unit 440 freeobjects that are not marked (step S22), and ends the GC controlprocessing.

Here, a simple description of the instruction execution processingperformed by the interpreter 1100 is given.

FIG. 18 is a flowchart showing instruction execution processing in thesecond embodiment.

As can be seen in the drawing, this instruction execution processing isessentially equivalent to the instruction execution processing shown inFIG. 13 with step S76 removed.

First, the instruction execution unit 110 interprets and executes theinstruction of the current execution location of the AP thread (stepS71), and the object reference detection unit 1120 judges whether or notthe GC flag 1460 is ON (step S72). If the GC flag 325 is not ON, theinstruction execution unit 110 interprets and executes the nextinstruction (step S71).

If the GC flag is judged to be ON at step S72, the object referencedetection unit 120 judges whether the instruction executed by theinstruction execution unit 110 at step S71 was an instruction thatprocesses an object pointer as a processing target (step S73), and ifnot, the instruction execution unit 110 interprets and executes the nextinstruction (step S71).

When it is judged at step S73 that the instruction was an instructionthat processes an object pointer as a processing target, the objectreference detection unit 120 judges whether data of the same value asthe object pointer has been stored in the object reference informationarea (step S74), and if so, the instruction execution unit 110interprets and executes the next instruction (step S71).

If it is judged at step S74 that data of the same value as the objectpointer has not been stored in the object reference information memoryarea, the object reference detection unit 120 stores the object pointerin the object reference information (step S75), and the instructionexecution unit 110 interprets and executes the next instruction (stepS71).

In this way the GC control unit 1410 selects one AP thread as a targetof reference processing by referring to the thread selection conditions,and after having the thread control unit 310 stop the selected thread,has the reference processing unit 1430 perform reference processingbased on the stack corresponding to the AP thread. Next, after havingthe thread control unit 310 remove the stop from the selected AP thread,the GC control unit 1410 repeats the described procedure until nounprocessed AP threads exist. Then the GC control unit 1410 has thethread control unit 310 release the stop from all AP threads, has thereference processing unit 1430 perform reference processing based on theobject reference information, has the thread control unit 310 remove thestop from all AP threads, and has the freeing unit 410 free all objectsthat are not marked.

3. Observations

The following gives a brief description of the differences betweenobjects managed by the described GC system of the present invention, andobjects in a conventional garbage collector in a Java executionenvironment or the like.

The GC system of the present invention shown in the first and secondembodiments, when executing an AP created with an object-orientedlanguage such as Java that relieves programmers from being concernedwith freeing of allocated memory, performs allocation of memory at thetime of generating an object and freeing the memory corresponding tothat object through a conventional OS memory management mechanism thatuses an MMU. This means that memory areas assigned for objects existtogether in the logical address space with memory areas assigned fornative data (i.e., data of programs created with other languages such asC language). FIG. 3 expresses this concept of co-existence.

In contrast, the state of Java objects managed by a conventional Javaexecution environment and data of, in this instance, a C languageprogram (hereinafter called “C data”) in a memory is shown in FIG. 19.

As shown in FIG. 19, C language programs 953 and 954 secure memory areasfor C data 921 and 922 in a random access memory (RAM) 900 via an OSmemory management mechanism.

Furthermore, Java objects 911 to 913 generated from the Java programs951 and 952 are allocated to a heap area 910, and management of an arraywithin the heap area 950 is performed not by the OS, but by the Javaexecution environment that includes a garbage collector 950. For thisreason, the Java execution environment first secures a heap area throughthe OS memory management mechanism, and then when generating the object,allocates one area within the heap area to the object. This heap areareduces the amount of memory that can be used for programs of otherlanguages.

Furthermore, when freeing an object, the Java execution environmentmanages an area allocated to the object in the heap area as an unusedarea that can be newly allocated to an object. However, it is necessaryto perform memory compaction in order to connect all unused areas in theheap area as required.

Note that in this respect, the GC system of the present invention asshown in the first and second embodiments does not perform heap areaallocation or management, but performs memory allocation for objectsdirectly through the conventional OS memory management mechanism.Therefore, memory compaction in a heap area is, naturally, unnecessary.

4. Additional Remarks

Although the GC system of the present invention has been described basedon the first and second embodiments, the present invention is notlimited to these embodiments. The following describes some possiblemodifications.

(1) Although the thread selection conditions are described as includingthree conditions, specifically, thread state, priority level and stacksize, which are given priority in the stated order, the number ofconditions and the order in which they are applied are not limited tothis example. For example, selection may be made giving priority tothreads with a high priority level, or to threads with a large stacksize.

However it should be noted that selecting an AP thread in a wait statefor the reference processing target as described in the embodiments willadversely effect the AP currently operating. Furthermore, the timerequired to perform reference processing (see FIG. 12) with respect toAPthreads according to a reference processing algorithm is shorter for APthreads for which reference processing is performed later than for APthreads for which reference processing is performed earlier. Therefore,by selecting low priority threads as reference processing targetsearlier as shown in the embodiments, the time for which high-priority APthreads that require immediate response are stopped can be reduced.Furthermore, for the same reason, since the time required for referenceprocessing is greater for larger stack sizes, by performing referenceprocessing in order of corresponding stack size starting from thesmallest corresponding stack size, the time for which AP threads arestopped can be distributed evenly to an extent between AP threads of thesame priority level.

(2) GC control processing is not limited to being performed in a fixedcycle based on a timer as described in the embodiments. Instead, GCcontrol processing may be performed when the amount of memory allocableto APs falls below a predetermined amount.

(3) The memory area of the object reference processing described in theembodiments may be a memory area expressed by a contiguous physicaladdress. Alternatively, a memory area of a set amount may beadditionally allocated when necessary at the time of storing an objectpointer, and the allocated segmented memory areas may be treated as acontinuous memory area in terms of logical address.

(4) In the GC system described in the first embodiment, when an objectpointer is the processing target in the instruction execution processingby the interpreter, and if the GC flag is ON, by performing processingto store the object pointer in the memory area of the object referenceinformation, and omitting, from the instruction execution processing,reference processing for moving data of the same value as the objectpointer from the from table, the speed of the instruction execution bythe interpreter is maintained. However, reference processing may beperformed during the instruction execution processing.

(5) In the embodiments, pointers to objects that can be reached fromobject pointers in the shared object management information are movedfrom the from table to the to table according to reference processing.However, it is not necessary to perform reference processing. It issufficient for objects that are managed according to the shared objectmanagement information to be excluded from being a target of freeing bythe freeing unit.

(6) The GC system shown in the embodiments is not limited to beingimplemented in a computer, but may be implemented a device that includesa CPU, such as a mobile terminal or home telephone.

(7) The thread control unit shown in the embodiments executes thethreads in series by switching between threads at minute intervals. Inother words, the thread control unit performs pseudo-parallel executionof the threads. However, the threads may actually be executed inparallel by a plurality of processor elements in a multiprocessor.

(8) In the embodiments, objects generated by the object generation unitare assigned memory in the logical address space by the conventional OSmemory management mechanism in the same way as native data. However,special management may be performed to assign memory to each object in aheap area that is one section in the logical address space. This specialmanagement may be realized by securing the heap area according to aconventional OS memory management mechanism, allocating an unallocatedarea in the heap area for generation of an object, and when an object isfreed, setting the corresponding area as an unused area. In this specialmanagement, it is necessary to further perform memory compaction inorder to connect the segmented unallocated areas in the heap area. Notethat for this reason, as shown in <3. Observations> this method of usinga heap area is not necessarily the optimal method.

(9) The GC system shown in the embodiments includes a conventional OSmemory management mechanism. However, an alternative is to provide theconventional OS memory management mechanism that manages memory using anMMU external to the GC system as a platform environment for the GCsystem. Here, the GC system secures and frees memory through theexternal memory management mechanism.

(10) A program for having a CPU executing the various processing (seeFIG. 8 to FIG. 14, FIG. 17, and FIG. 18) for realizing the functions ofthe GC system shown in the embodiments may be distributed recorded on arecording medium or via any of various types of communication paths.Examples of such a recording medium include an IC card, an optical disc,a flexible disk, and a ROM. The distributed program may be put to use bybeing stored in a memory or the like that is readable by a CPU in adevice that includes a CPU. The functions of the GC system shown in theembodiments are realized by CPU executing the program.

The GC system of the present invention may be used as an executionenvironment on a computer for APs (application programs) created in anobject-oriented programming language, such as Java, that relieves thecreators of the APs from being concerned with allocation and freeing ofmemory area.

1. A garbage collection system for freeing memory areas corresponding toobjects that are no longer required in an execution procedure of anobject-oriented program including a plurality of threads, the garbagecollection system comprising: a selection unit operable to select thethreads of the object-oriented program one at a time; an examinationunit operable to examine each selected thread, the examination including(i) stopping execution of a selected thread, (ii) finding an object thatis accessible from the selected thread by referring to an object pointerof the selected thread, (iii) managing the object found by the findingas a non-freeing target, and (iv) resuming execution of the selectedthread; a detection unit operable to, after the selection unit hascommenced selecting, (i) detect an object pointer that has beenprocessed as a processing target by a currently-executed thread, and(ii) manage an object identified by the object pointer detected as theprocessing target, as a non-freeing target; and a freeing unit operableto, after the examination unit has completed examining all of thethreads, free memory areas that correspond to objects other than theobjects that are managed as non-freeing targets, wherein: the detectionunit performs the detection only when the currently-executed thread hasnot yet been subject to examination by the examination unit; and thedetection unit includes: a finding sub-unit operable to, when thedetection has been performed, store, to a working memory area thatcorresponds to the currently-executed thread, the object pointerdetected as the processing target and an object pointer of an objectthat can be reached from the object pointer detected as the processingtarget; and a management sub-unit operable to, while the execution of aselected thread is being stopped by the examination unit, manage, as anon-freeing target, an object that can be reached from the objectpointer stored in the working memory area corresponding to thecurrently-executed thread.
 2. The garbage collection system of claim 1,wherein: when an object identified by an object pointer in a stackcorresponding to the selected thread is found to be accessible, theexamination of the examination unit repeatedly performs a procedure,only when both (a) the accessible object is not already being managed asa non-freeing target and (b) an object pointer exists in the accessibleobject, of further finding that an object identified by the objectpointer in the accessible object is accessible; the selection unit,after a first selection, further performs selection if, after theexamination of the first selection has been performed by the examinationunit, any threads of the plurality of threads remain that have not beensubject to the examination of the examination unit; and the selectionunit refers to information about the threads, and makes the selectionbased on one or more predetermined thread selection conditions.
 3. Thegarbage collection system of claim 2, wherein: the thread selectionconditions include a condition indicating that any threads having athread state that is a wait state are to be selected before any threadshaving a thread state that is a state other than the wait state; and ifa thread having a thread state that is the wait state exists when makingthe selection, the selection unit selects the thread having the statethat is the wait state.
 4. The garbage collection system of claim 3,wherein the thread selection conditions include a condition indicatingthat any threads having a thread priority level that is low are to beselected before any threads having a thread priority level that is high.5. The garbage collection system of claim 4, wherein the threadselection conditions include a condition indicating that any threadshaving a corresponding stack size that is small are to be selectedbefore any threads having a corresponding stack size that is large. 6.The garbage collection system of claim 5, further including a memorymanagement mechanism that manages memory with use of a memory managementunit, wherein each time an object is to be generated, a memory areacorresponding to the object is allocated by the memory managementmechanism, and wherein the freeing unit frees the memory areas via thememory management mechanism.
 7. The garbage collection system of claim2, wherein the thread selection conditions include a conditionindicating that any threads having a corresponding stack size that issmall are to be selected before any threads having a corresponding stacksize that is large.
 8. The garbage collection system of claim 2, whereinthe thread selection conditions include a condition indicating that anythreads having a thread priority level that is low are to be selectedbefore any threads having a thread priority level that is high.
 9. Thegarbage collection system of claim 1, further including a memorymanagement mechanism that manages memory with use of a memory managementunit, wherein each time an object is to be generated, a memory areacorresponding to the object is allocated by the memory managementmechanism, and wherein the freeing unit frees the memory areas via thememory management mechanism.
 10. A garbage collection method that, in acomputer, frees memory areas corresponding to objects that are no longerrequired in an execution procedure of an object-oriented programincluding a plurality of threads, the garbage collection methodcomprising: selecting the threads of the object-oriented program one ata time; examining each selected thread, the examining including (i)stopping execution of a selected thread, (ii) finding an object that isaccessible from the selected thread by referring to an object pointer ofthe selected thread, (iii) managing the object found by the finding as anon-freeing target, and (iv) resuming execution of the selected thread;after the selecting of the threads has commenced, (i) detecting anobject pointer that has been processed as a processing target by acurrently-executed thread, and (ii) managing an object identified by theobject pointer detected as the processing target, as a non-freeingtarget; and after the examining has completed examining all of thethreads, freeing memory areas that correspond to objects other than theobjects that are managed as non-freeing targets, wherein: the detectingis only performed when the currently-executed thread has not yet beensubject to the examining; and the detecting includes: when the detectinghas been performed storing to a working memory area that corresponds tothe currently-executed thread, the object pointer detected as theprocessing target and an object pointer of an object that can be reachedfrom the object pointer detected as the processing target; and while theexecution of a selected thread is being stopped by the examining,managing, as a non-freeing target, an object that can be reached fromthe object pointer stored in the working memory area corresponding tothe currently-executed thread.
 11. The garbage collection method ofclaim 10, wherein: the computer uses a memory management mechanism thatmanages memory with use of a memory management unit, and, in anexecution procedure of an object-oriented program, each time an objectis to be generated, allocates a memory area corresponding to the objectaccording to the memory management mechanism; and the freeing frees thememory areas via the memory management mechanism.
 12. Acomputer-readable storage medium having a computer program storedthereon, the computer program for having a computer execute garbagecollection processing that frees memory areas corresponding to objectsthat are no longer required in an execution procedure of anobject-oriented program including a plurality of threads, the computerprogram causing the computer to execute a method comprising: selectingthe threads of the object oriented-program one at a time; examining eachselected thread, the examining of including (i) stopping execution of aselected thread, (ii) finding an object that is accessible from theselected thread by referring to an object pointer of the selectedthread, (iii) managing the object found by the finding as a non-freeingtarget, and (iv) resuming execution of the selected thread; after theselecting of the threads has commenced, (i) detecting an object pointerthat has been processed as a processing target by a currently-executedthread, and (ii) managing an object identified by the object pointerdetected as the processing target, as a non-freeing target; and afterthe examining has completed examining all of the threads, freeing memoryareas that correspond to objects other than the objects that are managedas non-freeing targets, wherein: the detecting is only performed whenthe currently-executed thread has not yet been subject to the examining;and the detecting includes: when the detecting has been performed,storing, to a working memory area that corresponds to thecurrently-executed thread, the object pointer detected as the processingtarget and an object pointer in an object that can be reached from theobject pointer detected as the processing target; and while theexecution of a selected thread is being stopped by the examining,managing, as a non-freeing target, an object that can be reached fromthe object pointer stored in the working memory area corresponding tothe currently-executed thread.
 13. The garbage collection method ofclaim 12, wherein the computer uses a memory management mechanism thatmanages memory with use of a memory management unit, and, in anexecution procedure of an object-oriented program, each time an objectis to be generated, allocates a memory area corresponding to the objectaccording to the memory management mechanism; and the freeing step freesthe memory areas via the memory management mechanism.
 14. The garbagecollection system of claim 1, wherein the currently-executed thread is athread that is being executed according to reference processing.
 15. Thegarbage collection system of claim 14, wherein the execution that isstopped by the execution unit is execution by an interpreter.